Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GEkXEHqP+FDP0CI3"


--GEkXEHqP+FDP0CI3
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

Christopher J Peikert writes:
> In particular, I don't read any claim of N-6 bits of security over AES-128,
> for N=40 or any other value, in any specific scenario X, Y, Z, or otherwise.

Are you saying that NIST's "Taking Matzov's estimates of the attack cost
to be accurate" isn't considering the scenario that attacks cost 2^137
in what NIST calls "the RAM model"?

Are you saying that NIST's "something like 20 to 40 bits of security
more than would be suggested by the RAM model" isn't considering the
scenarios of adding, e.g., 20 or 40 to the above 137?

Are you saying that 137+20 isn't 157? Or that 137+40 isn't 177? NIST's
"20 to 40 bits ... more than" doesn't mean normal mathematical addition?

I'm not asking NIST to endorse the accuracy of the sources it's using.
I'm simply asking NIST to confirm

   (1) that, when it started from "Matzov's estimate" and then wrote "40
       bits of security more than what would be suggested by the RAM
       model", NIST was referring to security level 2^177; and

   (2) that NIST obtained this 40 from 169 minus 129 on page 103 of the
       NTRU Prime documentation, specifically "real" minus "free" for
       pre-quantum sieving for sntrup653.

Regarding #2, NIST says "the approximately 40 bits of additional
security quoted as the 'real cost of memory access' by the NTRUprime
submission"---but I don't see the source stating this 40. NIST should
explain how NIST obtained the 40 that it attributes to this source.

I came up with a simple explanation, namely the above 169-129, but so
far NIST hasn't confirmed that this is how it obtained the 40. It is not
appropriate for NIST to be using _my_ position on the NTRU Prime team as
an excuse to avoid clearly answering the question of how _NIST_ obtained
this 40 from the NTRU Prime documentation.

Regarding #1, I don't see how the original text leaves any ambiguities.
If NIST's text allows a different interpretation, why has nobody been
able to say what that alternative interpretation is? If NIST meant
something else, why hasn't it stated for the record what it meant?

It's weird that asking for confirmation of what _seems_ to be the plain
meaning of NIST's "more than" text---also matching the surrounding text
in NIST's posting; I've gone through every word of this in detail---is
producing so much resistance. Examples of the responses so far:

   * NIST's posting "speaks for itself". (Um, why not confirm that my
     understanding is correct, or else say what I missed?)

   * NIST was considering not just the 137 and the 40 but also further
     possibilities. (Yes, obviously, which is why my question began by
     explicitly focusing on one simple scenario as an example.)

   * I'm asking NIST for new technical evaluation. (No, I'm asking NIST
     a clarification question about calculations that NIST posted.)

   * Discussions of NIST's evaluation of the Kyber-512 security level
     should be terminated. (Um, what? This NIST security evaluation is
     the foundation of NIST's announced plan to standardize Kyber-512!)

Et cetera. None of this is proposing an alternative interpretation of
NIST's text, and all of this is taking far more time than would have
been taken by NIST simply clarifying one way or the other.

---D. J. Bernstein

-- 
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20230125153700.701538.qmail%40cr.yp.to.

--GEkXEHqP+FDP0CI3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3QolqQXydru4e4ITsMANTjsOVFkFAmPRTJwACgkQsMANTjsO
VFmVGBAAw3UCx6cN8LfjI8MwcWQJYzsfML95sUiaw1778nUsYv7JUzaOFVRKOuyj
jP43JOYaKjSpfJnpM8EXU6wL7/iQGHxaXZD2+zAV+EtKN9dMFfSZ1McAzEkMWBfo
uxRsebNyIYkpADf65saHjMhOxTYmueFTsfKccDayRYMnADlHQLw1eqWiafZRpGg4
QRJ7V5HkmvQiYVrdx91xFqOJjMUnTzY6wu1pOVmrouXZ9ixLnlXKsvUgYkK/AeP8
VDJPCt4SfcchXDVp+maV51GBVkqwj01ykZhn36Wb8KAahhRSHwZcfy5jidzfWemi
3WdiBQ1m1hkGBmE8GvrUUR8bueVeW2LFeEdPYNEC7VCvBpWHacDRFFEYsvfKYQj6
yYwwdT5/FPgdAaZZFqzGX27T8toE5em7FH7zCCY1m3OBMKKwBYsPSmfQlk0w4x1Y
VnNHTVdH+8tzEYqJo+EWbddSg84Uzbg3sDFe2gy/sEcwh2n2vo876uI787CaGxvh
pzsWMmkYFOL9Qan3AfoOCj4xPzKss1yw0oLpJ5Nw9NhPL5D5cSX38W1Bzg33beBu
wIy+xTsEZHhqC6CP3q4L1sP07tvQFstnJeYBjRizIrBjHwH1AUnOPmtDBpwtR+2O
tV93loMMOuXSoBplRLjlP22FIeGAcQ9N/N+0qZtRqXae1gWvapo=
=j+BL
-----END PGP SIGNATURE-----

--GEkXEHqP+FDP0CI3--